Open source

Journaux liées à cette note :

Alexandre me dit : « Le contenu de Speed of Code Reviews (https://google.github.io/eng-practices/review/reviewer/speed.html) ressemble à ce dont tu faisais la promotion dans notre précédente équipe ».

En effet, après lecture, les recommandations de cette documentation font partie de ma doctrine d'artisan développeur.

Note: j'ai remplacé CL qui signifie Changelist par Merge Request.

When code reviews are slow, several things happen:

The velocity of the team as a whole is decreased. Yes, the individual who doesn’t respond quickly to the review gets other work done. However, new features and bug fixes for the rest of the team are delayed by days, weeks, or months as each Merge Request waits for review and re-review.

Developers start to protest the code review process. If a reviewer only responds every few days, but requests major changes to the Merge Request each time, that can be frustrating and difficult for developers. Often, this is expressed as complaints about how “strict” the reviewer is being. If the reviewer requests the same substantial changes (changes which really do improve code health), but responds quickly every time the developer makes an update, the complaints tend to disappear. Most complaints about the code review process are actually resolved by making the process faster.

Code health can be impacted. When reviews are slow, there is increased pressure to allow developers to submit Merge Request that are not as good as they could be. Slow reviews also discourage code cleanups, refactorings, and further improvements to existing Merge Request.

source

J'ai fait le même constat et je trouve que cette section explique très bien les conséquences 👍️.

How Fast Should Code Reviews Be?

If you are not in the middle of a focused task, you should do a code review shortly after it comes in.

One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).

Following these guidelines means that a typical Merge Request should get multiple rounds of review (if needed) within a single day.

source

Je partage et recommande cette pratique 👍️.

If you are too busy to do a full review on a Merge Request when it comes in, you can still send a quick response that lets the developer know when you will get to it, suggest other reviewers who might be able to respond more quickly.

source

👍️

Large Merge Request

If somebody sends you a code review that is so large you’re not sure when you will be able to have time to review it, your typical response should be to ask the developer to split the Merge Request into several smaller Merge Requests that build on each other, instead of one huge Merge Request that has to be reviewed all at once. This is usually possible and very helpful to reviewers, even if it takes additional work from the developer.

source

Je partage très fortement cette recommandation et je pense que c'est celle que j'avais le plus de difficulté à faire accepter par les nouveaux développeurs.

Quand je code, j'essaie de garder à l'esprit que mon objectif est de faciliter au maximum le travail du reviewer plutôt que de chercher à minimiser mes propres efforts.

J'ai sans doute acquis cet état d'esprit du monde open source. En effet, l'un des principaux défis lors d'une contribution à un projet open source est de faire accepter son patch par le mainteneur. On comprend rapidement qu'un patch doit être simple à comprendre et rapide à intégrer pour maximiser ses chances d'acceptation.

Un bon patch doit remplir un objectif unique et ne contenir que les modifications strictement nécessaires pour l'atteindre.

Je suis convaincu que si une équipe de développeurs applique ces principes issus de l'open source dans leur contexte professionnel, leur efficacité collective s'en trouvera grandement améliorée.

Par ailleurs, une Merge Request de taille réduite présente plusieurs avantages concrets :

elle est non seulement plus simple à rebase,
mais elle a aussi plus de chances d'être mergée rapidement.

Cela permet à l'équipe de bénéficier plus rapidement des améliorations apportées, qu'il s'agisse de corrections de bugs ou de nouvelles fonctionnalités.

Je viens de tomber dans un Yak! 🙂.

Je cherchais des alternatives Open source à ngrok et j'ai trouvé sish (https://docs.ssi.sh/).

Côté client, sish utilise exclusivement ssh pour exposer des services (lien la documentation).

Voici comment exposer sur l'URL http://hereiam.tuns.sh le service HTTP exposé localement sur le port 8080 :

$ ssh -R hereiam:80:localhost:8080 tuns.sh

Je trouve cela très astucieux 👍️.

Après cela, j'ai commencé à étudier comment déployer sish et j'ai lu cette partie :

This includes taking care of SSL via Let's Encrypt for you. This uses the adferrand/dnsrobocert container to handle issuing wildcard certifications over DNS.

source

Après cela, j'ai étudié dnsrobocert qui permet de générer des certificats SSL Let's Encrypt avec la méthode DNS challenges, mais pour cela, il a besoin d'insérer et de modifier des DNS Record sur un serveur DNS.

Je n'ai pas envie de donner accès à l'intégralité de mes zones DNS à un script.
Pour éviter cela, j'ai dans un premier temps envisagé d'utiliser un serveur DNS managé de Scaleway, mais j'ai constaté que le provider Scaleway n'est pas supporté par Lexicon (qui est utilisé par dnsrobocert).

Après cela, j'ai décidé d'utiliser PowerDNS et je viens de publier ce playground : powerdns-playground.

#JaiDécouvert le projet Match ID (https://matchid.io/) et plus précisément l'instance deces.matchid.io (https://deces.matchid.io/search).

Le projet matchID a été initié au ministère de l'Intérieur dans le contexte des challenges d' Entrepreneur d'intérêt général. La réconciliation des personnes décédées avec le permis de conduire a été le premier cas d'usage réalisé avec matchID.

Le projet a été libéré et mis en open source. L'équipe est maintenant composée de développeurs, anciens du ministère de l'Intérieur, contribuant bénévolement au service sur leur temps libre.

Nous avons créé ce service en complément, car il semblait d'utilité publique notamment pour la lutte contre la fraude, ou pour la radiation des décédés aux différents fichiers clients (e.g. hôpitaux).

L'exposition sur deces.matchid.io au profit du public est assurée par Fabien ANTOINE, avec le soutien de Cristian Brokate notamment pour le soutien technique à l'API. Le service est offert sans garantie de fonctionnement, nous nous efforçons de répondre aux messages (hors "absence du fichier") sur notre temps libre, faut de support officiel par les services de l'Administration.

Pour en savoir plus sur le projet matchID, consultez notre site https://matchid.io.

source

#Jadore ❤️

Le site exploite les fichiers des personnes décédées, disponibles en open data sur data.gouv.fr et recueillies par l'INSEE.

Les fichiers des personnes décédées sont établis par l’INSEE à partir des informations reçues des communes dans le cadre de leur mission de service public.

Quelques informations sur le fichier :

le fichier comporte 27983578 décès et NaN doublons (stricts)

il comporte les décès de 1970 à aujourd'hui (jusqu'au 31/10/2024)

il a été mis à jour le 05/11/2024

source

Un projet open source du Ministère de l'Intérieur.

Par curiosité, j'ai cherché des alternatives open-source à Customer.io, voici ce que j'ai trouvé :

LimeJourney, projet d'un Solo Développeur, débuté en août 2024 (from)
Laudspeaker, projet débuté en octobre 2022 (from)
Dittofeed, projet Californien, codé par Max Gurewitz et Chandler Craig (marketing), incubé par Y Combinator, débuté en septembre 2022 (from) J'ai lu ces autres threads de Chandler Craig :
- Building messaging automation is a waste of time
- Show HN: Open-source low-code email editor

Il y a quelques mois, on m'avait partagé le projet NanoKVM.

Alexandre m'a partagé un autre projet du même type : JetKVM.

Next generation open-source KVM over IP for $69

Le blog de Jeff Geerling contient deux articles de test de KVM :

Test du NanoKVM : Sipeed NanoKVM: A RISC-V stick-on
Test du JetKVM : JetKVM: tiny IP KVM that's not an Apple Watch

Je rassemble ici quelques notes au sujet de projet Hasura.

À l'origine, Hasura était uniquement un moteur GraphQL open-source qui se branchait directement sur une base de données PostgreSQL. Le projet a commencé en 2018, bien que le site web soit plus ancien — 2015.
D'après le dépôt GitHub, les premiers développeurs d'Hasura sont Shahidh K Muhammed, Vamshi Surabhi, Aravind Shankar et Rakesh Emmadi, tous basés à Bangalore, en Inde.

En 2019, dans un cadre professionnel, j'ai choisi d'utiliser un autre moteur GraphQL : PostGraphile.

Début 2020, j'avais également identifié Hasura et Supabase comme alternatives.

J'avais choisi d'utiliser PostGraphile pour plusieurs raisons :

Supabase était encore un jeune projet, lancé en octobre 2019.
Hasura était codé en Haskell, un langage que je ne maîtrise pas. En revanche, PostGraphile, développé en JavaScript, m'inspirait plus confiance, car je savais que j'avais les compétences nécessaires si je devais intervenir sur son code source, par exemple, pour corriger un bug.
D'autre part, PostGraphile n'était pas financé par des Venture capital, ce qui m'inspirait bien plus confiance sur son avenir que Supabase et Hasura.
J'apprécie énormément la façon de travailler de Benjie. J'apprécie sa manière d'organiser ses projets, ses documentations et ses choix techniques. Je pense que notre doctrine est assez similaire.

Quatre plus tard, je constate que PostGraphile a choisi de rester concentré sur un seul objectif : être un moteur GraphQL, tandis que Supabase et Hasura, bénéficiant d'un financement par des Venture capital, ont diversifié leurs offres.

Alors que PostGraphile se limite au support de PostgreSQL, Hasura peut se connecter à Mysql, MongoDB, Clickhouse, Elasticsearch…
Et d'après la documentation, Hasura permet d'exposer, en plus d'une API GraphQL, une API REST (RESTified Endpoints).

En étudiant social.coop #JaiDécouvert Loomio.

J'ai testé Loomio en septembre 2014, comme outil de prise de décision pour l'association Coworking Metz. Je ne me souviens plus pourquoi ce test n'a pas été concluant. Peut-être que le projet était trop jeune.

Loomio a émergé en 2012 du mouvement dit "Occupy movement" et a été développé dans une entreprise sociale néo-zélandaise. Il a bénéficié d'une campagne internationale de crowfunding en 2014.

La société emploie actuellement 11 personnes.

-- from

Je constate que le projet a commencé réellement en 2011 et qu'il est très actif. Il semble être principalement développé par l'un des fondateurs : Robert Guthrie.

Loomio est une application open source, codée en Ruby on Rails.

Loomio est plus minimaliste que Decidim et Cap Collectif.
Je pense que Loomio est mieux adapté au prise de décision interne d'une association, une coopérative ou d'une équipe.

Je suis un utilisateur notice de Loomio. Voici ce que j'ai compris en explorant mes workspaces et la documentation utilisateur.

Le type ressource de base de Loomio est le "Thread", « Fil de discussion » en français.

Dans le screenshot ci-dessus, 4 modèles de fil de discussion sont configurés au niveau du projet, mais Loomio propose de nombreux autres modèles de fil de discussion, il est même possible d'en construire de nouveaux :

Ensuite, il est possible de poster des commentaires dans le fil de discussion :

ou alors poster une décision à prendre. Loomio propose 11 types de prise de décision :

Proposition :
- Vérification des sens - Demandez des commentaires, des questions et des préoccupations ;
- Conseil - Demandez conseil sur une décision que vous devez prendre ;
- Consentement - Prendre une décision "sûre à essayer", sans objections ;
- Consensus - Parvenir à une convention collective avec toutes les personnes impliquées ;
- Gradients d'accord - Soutien express pour une proposition sur une échelle de 8 points.
Sondage :
- Sondage simple - Trouvez l'option la plus populaire ;
- Vote pondéré - Mesurer le degré de soutien pour chaque option ;
- Vote à points - Allouer un budget de points pour révéler les priorités ;
- Classement par préférence - Comprendre la préférence ordonnée des options.
Réunion :
- Nouveau sondage horaire de réunion - Trouver quand les gens sont disponibles pour se rencontrer ;
- Opt-in - Trouvez des volontaires ou demandez des participants.

Voici les screenshots des sections. La sélection de chaque type de propositions envoie vers un formulaire spécifique. Je n'ai pas réalisé un screenshot pour ces 11 types.

Loomio permet aussi de tout de suite poster une demande de décision sans passer par un thread.

Il est possible de poster plusieurs décisions au cours de la vie d'un thread.
Je trouve cette fonctionnalité très flexible.

Loomio supporte les threads ainsi que les réactions au niveau des commentaires :

Loomio affiche une timeline à droite des threads qui contiennent une mise en avant des prises de décisions :

Autre fonctionnalité que j'apprécie : il est possible de consulter quels utilisateurs ont reçu des notifications et qui ont lu le message.

Je vous invite à consulter la note "Les 4 méthodes de prises de décisions de Loomio".

#JaiDécouvert et un peu étudié Temporal (workflow management).

D'après ce que j'ai compris, Temporal a été initialement développé par les auteurs (Maxim Fateev et Samar Abbas) de Cadence.

Je me souviens d'avoir étudié Cadence vers 2019. J'ai l'impression que ce projet est encore très actif. #JeMeDemande quelles sont les réelles différences entre Temporal et Cadence 🤔.

Une première réponse à ma question :

Temporal supporte les langages Go, Java, PHP, Python, TypeScript, dotNET alors que Cadence est limitée aux langages Go et Java.
Cadence propose une UI nommée cadence-web qui semble plus minimaliste que temporalio/ui.

D'après ce que j'ai lu, Temporal est totalement open-source, sous licence MIT. L'entreprise Temporal propose une version hébergée (managée) nommée Temporal Cloud.

#JaiDécouvert un exemple de projet d'Order Management System codé en Go et basé sur Temporal : https://github.com/temporalio/reference-app-orders-go.
Je n'ai pas étudié le code source, mais c'est un sujet qui m'intéresse, étant donné que j'ai travaillé par le passé sur le développement d'un Order Management System 😉.

#JaiLu ce thread Hacker News : Rrweb – record and replay debugger for the web.

#JaiDécouvert highlight.io, replay.io, Zipy et wirequery qui semblent être des alternatives à Posthog et OpenReplay.

Tous ces outils sont basés sur rrweb.

wirequery semble être un projet 100% open source.

#JaiDécouvert un autre projet basé sur rrweb : RecordOnce pour générer des tutoriels.

Alexandre m'a partagé Continue.

Continue is the leading open-source AI code assistant. You can connect any models and any context to build custom autocomplete and chat experiences inside VS Code and JetBrains

Je lis ici que ce projet peut être assimilé à avante.nvim ou llm.nvim.

Je constate qu'il est possible de connecter Continue à beaucoup de types de LLM : Model Providers.

D'autre part, chose intéressante, Continue permet d'intégrer facilement du contexte provenant de diverses sources, telles que :

Je me pose toujours la même question que le 27 août :

Cependant, une question me revient sans cesse à l'esprit en voyant ce genre d'outil utilisant les API d'AI Provider : est-ce que le coût d'utilisation de ce type de service ne risque pas d'être exorbitant ? 🤔 Je sais bien que ces AI Provider permettent de définir un plafond de dépenses, ce qui est rassurant. La meilleure approche serait donc de tester l'outil et d'évaluer les coûts mensuels pour voir s'ils restent raisonnables.